Avoidance of inconsistencies during the virtual integration of vehicle software

functional definition. This uses the results from the level above and models the common system specification. Based on these abstract functional definitions, the Functional Design Architecture of EAST-ADL can be used to model a system architecture and a detailed functional design as well. These levels capture information before module specification and implementation. After that, the more specific artifacts for implementation specifications of EAST-ADL can be derived from the former specifications. For this purpose, EAST-ADL2 specific “ADLRealization”-dependencies between abstraction levels are used to record traceability from abstract levels down to more specific levels. 2.2.3. EAST-ADL2 vs. SEA-AADL and other approaches Section 2.2.1 lists a lot of ADLs. As such, each of them enable a description of common architectures containing components and interconnections among them. But the nature of these ADLs is mostly either aligned with a theoretical and academical background or not aligned with specific domains or both in the majority of cases. For this reasons and because there are two languages already, EASTADL2 and SAE-AADL, more specific to the needs of automotive system development, just these two approaches will be discussed below. The SAE-AADL language comes closest to the facilities of EAST-ADL2(compare section 2.2.2). IN 2004 SAE-AADL was renamed from “Avionic Analysis and Design Architecture” to “Architecture Analysis and Design Language”. Although it was developed by SAE, the Society of Automotive Engineers, it was originally intended for avionic systems. However, by now the AADL is also being used within other domains, such as Space, Robotics, Industrial Control, Medical, and Automotive. Table 2.1 bases on [37] and clarifies big differences and commonalities of these two languages. SAE-AADL is a more common approach usable for various domains than EAST-ADL2. However, a comparison between the two languages shows that EAST-ADL2 can complement SAE-AADL, and vice versa. Both languages enable modeling of static, software-intensive embedded systems. On the one hand, while SAE-AADL can be used for modeling and analysis on a level close to implementation, it is possible to use EAST-ADL2 for design modeling and validation on a high level of abstraction. Especially, well supported possibilities for analysis and tool usage make SAE-AADL interesting. EAST-ADL2 though, provides theoretical concepts for analysis, but there are just a few tools supporting or executing these analyzes. On the other hand EAST-ADL2 supports modeling of behavior, which is not considered by SAE-AADL. This makes it possible to integrate behavior models, like State-Chartsor Use-Case-Diagrams into a EAST-ADL2 model. Additionally, EAST-ADL2